At present, in the cloud computing environment, most Software as a Service (SaaS) applications support multi-tenancy. For example, many enterprises use email service from one service provider via the Internet or worldwide web. Each of the enterprises uses the same interface for filling out authentication information such as an enterprise ID and password when logging onto the website, and accepts the same service process, but information for each enterprise is isolated. An enterprise cannot see the information of others. Here, each enterprise is a tenant. A tenant comprises a plurality of personal accounts, including personal accounts of administrators and common employees.
Currently, information of the tenants is isolated from each other primarily through three approaches. The first approach is to use separate servers for different tenants. The second approach is to use a plurality of databases on the same server for different tenants. The above two approaches are suitable for those tenants whose amount of information to be maintained is comparatively large. For those tenants whose amount of information to be maintained is comparatively small, a third approach is often adopted, that is, information of multiple tenants is maintained in the same database but isolated inside the database in a table level. For example, the database has a plurality of tables, and each of them is shared by a plurality of tenants.
FIG. 1 is a block diagram of a database system 400 in the prior art. The database system 400 comprises a database management system (“DBMS”) 402 and a database 403. In addition, the database 403 has an automatic data event logging mechanism, i.e., data event logger 404. When a tenant wishes to perform a query, insertion, deletion or update on records in the database 403 (in fact on records in the tables database 403, which are hereinafter referred to as records in the database), an application 401 sends a SQL request to the database management system 402. The database management system 402 performs the query, insertion, deletion or update on the database 403, according to the request. If the request is a query request, the query result is then returned to the application 401. When the contents of the database 403 are changed (that is, the request is an insertion, deletion or update request), the data event logger 404 automatically logs the change as an event. Specifically, when the change is an insertion, a newly inserted record is logged; when the change is a deletion, a deleted record is logged; when the change is an update, records before the update and after the update are logged both.
In the case of isolation inside database, in order to reduce information loss caused by database failure or effects of a tenant's wrong operation on the database, a backup database is provided and keeps the content synchronized with the original database at backup points periodically. However, a great shortcoming of the prior art is that once a tenant performs a wrong operation on the database and thus wishes to roll back to a backup point, all the tenants data in the database must roll back to the backup point simultaneously, thereby affecting other tenants.
FIG. 2 shows two backup points, A and B. When the tenant A finds at the current time that a wrong operation was performed on the database and thus wishes to roll back to the backup point B, a restoration operation has to be performed not only on data of the tenant A but also simultaneously on data of tenants B and C—who do not wish to roll back to the backup point B.